\documentclass[a4paper,10pt]{article}
\usepackage[spanish]{babel} % Paquetes de idioma
\usepackage[latin1]{inputenc} % Paquetes de idioma
\usepackage{graphicx} % Paquete para ingresar gráficos
\usepackage{grffile}
\usepackage{hyperref}
\usepackage{fancybox}
\usepackage{amsmath}
\usepackage{listings}
\usepackage{color}

% Encabezado y Pié de página
\input{EncabezadoyPie.tex}
% Carátula del Trabajo
\title{ \input{Portada.tex} }

\begin{document}
	\maketitle % Hace que el título anterior sea el principal del documento
	\newpage

	\tableofcontents % Esta línea genera un indice a partir de las secciones y subsecciones creadas en el documento
	\newpage

	\section{An\'alisis del problema}
		El presente trabajo consiste en el desarrollo de una aplicaci\'on {\it concurrente} que permita la simulaci\'on del control de un ascensor de un 
		edificio.\\
		\indent Dicha aplicaci\'on deber\'a ser desarrollada en lenguaje C o C++ y funcionar en una \'unica computadora bajo ambiente Unix/Linux.\\
		\indent Dado que el objetivo es que el resultado de la simulaci\'on se parezca lo mayor posible a la realidad, se deben recibir como par\'ametros ciertas 
		caracteristicas del ascensor:
			\begin{itemize}
			 \item La cantidad de pisos del edificio.
			 \item La velocidad de desplazamiento del ascensor.
			 \item La capacidad (en cantidad de personas) del ascensor
			\end{itemize}
		Adem\'as de lo anteriormente mencionado, la aplicaci\'on debe recibir el tiempo durante el cual se desea que se ejecute la simulaci\'on.\\
		\indent La interfaz gr\'afica solo mostrar\'a en pantalla sucesos b\'asicos del programa. El resultado detallado de la simulaci\'on se almacenar\'a en un archivo de Log bajo el nombre 
		\textquotedblleft {\it Log\textless fecha\textgreater\textless hora\textgreater.txt} \textquotedblright, en el cual quedar\'an registradas todas las acciones llevadas a cabo por los 
		diferentes procesos.
		
		\vspace{0.5cm}
		
		\subsection {Casos de uso}
			\subsubsection {Diagrama de Casos de uso}
				\begin{figure}[!htpb]
					\centering
					\includegraphics[width=12cm]{Casos de uso/casosDeUso.png}
					\caption{Diagrama de Casos de Uso}
				\end{figure}
				\newpage
			\subsubsection {Documentaci\'on de Actores}
			\begin{itemize}
					\item \textbf{Persona:} Son los usuarios que llegan aleatoriamente a los diferentes pisos con la intenci\'on de utilizar al ascensor. Su 
					interacci\'on con el mismo se limita a realizar un pedido, y a cambiar dicho pedido una vez adentro del ascensor.
					\item \textbf{Controlador:} Es la entidad encargada de recibir los pedidos por parte de los pisos, a medida que le llegan las llamadas le 
					informa al ascensor acerca de las mismas.
					\item \textbf{Ascensor:} En este contexto, se utiliza al ascensor como el encargado de transportar entre los diferentes pisos a las 
					personas que lo requieran. Recibe los pedidos por parte del controlador, y a las personas por parte del piso.
					\item \textbf{Terminador:} El actor \textquotedblleft Terminador \textquotedblright  tomar\'ia el rol del tiempo en el sistema, puesto que es 
					el encargado de una vez finalizado el tiempo de simulaci\'on, detener a todos los procesos que participan en la misma.
			\end{itemize}
			\subsubsection {Documentaci\'on de Casos de uso}
			\indent A continuaci\'on se procede a especificar los casos de uso mostrados en el diagrama anterior. Dado que la magnitud del sistema desarrollado no presenta
			casos de uso muy complicados, se omitiran los Subflujos y los Flujos de Excepci\'on a menos que se especifiquen explicitamente. 
			\begin{enumerate}
				\item \textbf{Solicitar Ascensor:} Permite a la persona indicarle al ascensor que desea subirse al mismo.\\
					\begin{itemize}
						\item \textbf{Precondiciones:}\\
							El ascensor debe estar funcionando, el controlador debe estar a la escucha de nuevos
							pedidos y el tiempo de simulaci\'on no debe haber terminado\\
						\item \textbf{Flujo principal:}\\
							El piso crea una nueva persona\\
							Se genera una lamada para dicha persona\\
							Se agrega la llamada al pipe de llamadas\\
							Se coloca a la persona en el pipe que le corresponda de acuerdo a si desea subir o bajar\\
					\end{itemize}
				\item \textbf{Subir al Ascensor:} 
					\begin{itemize}
						\item \textbf{Precondiciones:}\\
							Se debe haber realizado una llamada al ascensor previamente.\\
						\item \textbf{Flujo principal:}\\
							El ascensor llega al piso en cuestion\\
							Si la capaciad llego a su limite (S1)\\
							Si no (S2)\\
						\item \textbf{Subflujos:}\\
							S1: El ascensor evita que ingrese la persona y acola el pedido nuevamente para resolverlo en el futuro.\\
							S2: La persona ingresa al ascensor y modifica su pedido para indicar a que piso se dirije.
					\end{itemize}
				\item \textbf{Realizar Llamada:} 
					\begin{itemize}
						\item \textbf{Precondiciones:}\\
							El ascensor debe estar funcionando.\\
						\item \textbf{Flujo principal:}\\
							El controlador coloca la informaci\'on de la llamada en la memoria compartida\\
							Una vez colocada la informaci\'on le avisa al ascensor del nuevo pedido por medio de una se\~nal\\
							Una vez realizada la llamada, el controlador vuelve a quedar a la escucha de nuevos pedidos\\
					\end{itemize}
				\item \textbf{Resolver Pedido:} 
					\begin{itemize}
						\item \textbf{Precondiciones:}\\
							Una persona debe haber llegado a un piso, y el mismo debe haber generado un pedido.\\
						\item \textbf{Flujo principal:}\\
							El ascensor llega al piso que gener\'o el pedido\\
							Se bajan todas aquellas personas que viajaban hasta ese piso\\
							Mientras puedan ingresar personas, ingresan aquellas que les corresponde (es decir las que desean viajar 
							en la misma direcci\'on que lo hace el ascensor) \\
							Si quedan personas en el piso y se alcanzo la capacidad m\'axima (S1)\\
							El ascensor continua resolviendo los pedidos\\
						\item \textbf{Subflujos:}\\
							S1: Se deja a la persona esperando, y se reacomoda su pedido para ser tratado en el futuro.\\
					\end{itemize}
				\item \textbf{Finalizar simulaci\'on:} 
					\begin{itemize}
						\item \textbf{Precondiciones:}\\
							En este caso no existe ning\'una precondici\'on, el Terminador puede finalizar la ejecuci\'on porque 
							termin\'o el tiempo de simulaci\'on o porque ocurri\'o alg\'un error durante la misma.\\
						\item \textbf{Flujo principal:}\\
							El Terminador le envia una se\~al a todos los procesos que intervienen en la simulaci\'on para que terminen sus
							ejecuciones de forma ordenada.\\
					\end{itemize}
			\end{enumerate}
			
			
		

	\section{An\'alisis de la Soluci\'on}
		\subsection{Divisi\'on del programa en procesos}
			Para la divisi\'on de los procesos se tuvo en cuenta el comportamiento real de un ascensor:
			\begin{itemize}
				\item \textbf{Ascensor:} Es el proceso que se encaga de simular el movimiento del ascensor. Para ello cuenta con una lista de pedidos en la 
				cual se encuentran tanto los pedidos externos que se le hacen al ascensor, asi como tambi\'en, los pedidos que realizan las personas que 
				ingresan al mismo. Cuando dicha lista este vac\'ia, el proceso quedar\'a a la espera de nuevos pedidos.
				\item \textbf{Controlador:} En este caso, el proceso se encarga de la comunicaci\'on entre el \emph{ascensor} y los distintos \emph{pisos}. 
				Cuando una nueva persona solicita al ascensor, es el proceso controlador el que detecta dicha llegada y le avisa al ascensor del nuevo pedido. 
				Al igual que el caso anterior, este proceso quedar\'a siempre a la escucha de nuevas solicitudes.
				\item \textbf{Piso:} Como se mencion\'o anteriormente, para la divisi\'on de procesos se tuvo en cuenta el comportamiento real de un ascensor, 
				en el mismo, la llegada de personas a cada piso es independiente del resto de los pisos y por lo tanto no deber\'ia haber relaci\'on alguna 
				entre los mismos. Para simular esto se utilizar\'a un proceso por cada piso del edificio que regule el comportamiento del mismo. Dicho proceso 
				se encargar\'a de las llegadas aleatorias de personas que requieran el ascensor. Mediante esta soluci\'on el principal logr\'o que se obtuvo es
				permitir que dos personas lleguen en el mismo instante de tiempo a pisos diferentes, sin que ninguna sea condicionada en su llegada por la otra.
				\item \textbf{Terminador:} Este proceso es el principal de la aplicaci\'on y es el que se lanza cuando la misma se ejecuta. Todos los demas 
				procesos son lanzados por este. Una vez creados todos los objetos y lanzados todos los procesos, el terminador queda suspendido el tiempo que 
				se indic\'o que debe durar la simulaci\'on. Una vez transcurrido dicho intervalo de tiempo, el proceso \emph{terminador} debe finalizar la 
				ejecuci\'on de todo el resto de los procesos creados.
			\end{itemize}

		\subsection{Esquema de comunicaci\'on entre procesos}
			A continuaci\'on se detalla como es la comunicaci\'on entre los diferentes procesos mencionados en el item anterior:
			\begin{itemize}
				\item \textbf{Comunicaci\'on entre el piso y el controlador:}\\
						Cada piso, cada un intervalo aleatorio de tiempo crea una nueva persona, la cual desea ingresar al ascensor. Cuendo esto sucede
						se le debe indicar al mismo que un piso lo requiere. El encargado de dicha comunicaci\'on es el controlador. Es decir que con 
						cada nueva persona que arriba a un piso, se le informa (mediante alg\'un mecanismo que se indicar\'a mas adelante) al controlador
						que en un piso determinado realiz\'o un pedido. En este caso, la \'unica informaci\'on que se intercambia es el n\'umero de piso que
						realizo el pedido, y si la persona que lo realiz\'o desea ir a un piso arriba o abajo del actual.
				\item \textbf{Comunicaci\'on entre el controlador y el ascensor:}\\	
						Cuando el controlador detecta que a un piso, arrib\'o una nueva persona, este le indica al ascensor que debe acolar un nuevo pedido
						a resolver. Al igual que el caso anterior, la \'unica informaci\'on que se intercambia es el piso al que arribo la nueva persona,
						y si esta desea ir a un piso m\'as arriba o m\'as abajo del actual.
				\item \textbf{Comunicaci\'on entre el ascensor y el piso:}\\
						Al llegar a un determinado piso, el ascensor debe obtener del mismo las personas que lo requirieron en dicho piso. La informaci\'on 
						que intercambian ambos procesos es precisamente las personas que se encontraban en el piso a la espera del ascensor.
				\item \textbf{Comunicaci\'on entre el terminador y el piso:}\\
						Una vez que la simulaci\'on deba finalizar, el terminador comienza avis\'andole a todos los pisos que el ascensor ya no puede recibir 
						m\'as solicitudes, y por lo tanto deben finalizar su ejecuci\'on. Dado que el terminador solo le indica al piso que debe finalizar, no 
						existe ning\'un intercambio de datos en este caso.
				\item \textbf{Comunicaci\'on entre el piso y el controlador:}\\
						En este caso la comunicaci\'on se di\'o inmediata dado la soluci\'on que se eligi\'o para la misma, sin embargo la idea es que todos 
						los pisos le indiquen al controlados que finalizaron su ejecuci\'on, as\'i este puede finalizar su ejecuci\'on de forma ordenada.
				\item \textbf{Comunicaci\'on entre el terminador y el ascensor:}\\
						Al igual que el caso anterior, una vez que el terminador le indic\'o a todos los pisos que deben finalizar su ejecuci\'on, debe hacer 
						lo propio con el ascensor, para que este deje de aceptar nuevos pedidos, y termine los pedidos que ten\'ia acolados.
			\end{itemize}

		\subsection{Mapeo de la comunicaci\'on en los problemas conocidos de concurrencia}
			La idea de esta secci\'on es la de buscar alguna relaci\'on entre los problemas comunes de la concurrencia vistos en clase y los problemas que se plantearon 
			en el desarrollo del trabajo.\\
			\indent Para comenzar, se enuncian brevemente los problemas conocidos de concurrencia:\\
			\begin{itemize}
				\item \textbf{Fil\'osofos comensales:} Este problema, fue planteado originalmente por Edsger Dijkstra en el a\~no 1965 y es como sigue. Cinco 
					fil\'osofos se sientan alrededor de una mesa y pasan su vida cenando y pensando. Cada fil\'osofo tiene un plato de fideos y un tenedor a la izquierda 
					de su plato. Para comer los fideos son necesarios dos tenedores y cada fil\'osofo s\'olo puede tomar los que est\'an a su izquierda y derecha. Si 
					cualquier fil\'osofo toma un tenedor y el otro est\'a ocupado, se quedar\'a esperando, hasta que se libere el otro tenedor, para luego empezar a comer. 
					Si dos fil\'osofos adyacentes intentan tomar el mismo tenedor a la vez, se produce una condici\'on de carrera: ambos compiten por tomar el mismo tenedor,
					y uno de ellos se queda sin comer. Si todos los fil\'osofos toman el tenedor que est\'a a su derecha al mismo tiempo, entonces todos se quedar\'an 
					esperando eternamente, porque alguien debe liberar el tenedor que les falta. Nadie lo har\'a porque todos se encuentran esperando que alguno deje sus 
					tenedores. El problema consiste en encontrar un algoritmo que permita que los fil\'osofos no se mueran de hambre.
				\item \textbf{Productor/Consumidor:} Se tienen dos familias de procesos, una familia de procesos productores, y otra familia de procesos consumidores.
					Se tiene tambi\'en un repositorio, en el cual cualquier productor coloca alg\'un producto y cualquier consumidor lo retira. En la soluci\'on a este 
					problema se deben cumplir las siguientes premisas:\\
					\begin{enumerate}
						\item No se puede consumir lo que no existe.
						\item Al repositorio se accede de a uno.
						\item Se consumen los items en el mismo orden que se producen
					Hay una variante del problema que se da cuando el repositorio es acotado, lo que agrega una nueva premisa:
						\item No se puede producir si no hay lugar en repositorio.
					\end{enumerate}
				\item \textbf{Lector/Escritor:} Es un problema my parecido al caso anterior (\emph{Productor/Consumidor}), en el cual se asume que el repositorio 
					(en este caso denominado \'area de escritura/lectura) es ilimitado. En este caso las premisas son como se enuncian a continuaci\'on:
					\begin{enumerate}
						\item Todos los lectores pueden ingresar concurrentemente al \'area de lectura, siempre que no haya un escritor escribiendo.
						\item Un escritor puede escribir, siempre que no haya un lector leyendo, u otro escritor escribiendo.
					\end{enumerate}
			\end{itemize}
			\indent A continuaci\'on se muestra en cada caso, con que problema de la concurrencia se mapea la comunicaci\'on entre diferentes procesos:
				\begin{itemize}
					\item \textbf{Comunicaci\'on entre el piso y el controlador:}
					Este primer caso, se trat\'o como si fuera un productor/consumidor, en donde cada uno de los pisos cumple el papel de un productor que 
					deposita pedidos en un buffer, y el controlador cumple el rol de consumidor y lee del buffer.
					\item \textbf{Comunicaci\'on entre el controlador y el ascensor:}
					Al igual que el caso anterior, este problema se trato como si fuera un productor/consumidor, s\'olo que esta vez el controlador tomo el 
					papel de productor, mientras que el ascensor es el consumidor. Una diferencia sustancial con el primer caso es que ahora s\'olo se cuenta
					con un \'unico productor y un \'unico consumidor.
					\item \textbf{Comunicaci\'on entre el ascensor y el piso:}
					Como en los dos casos anteriores, la comunicaci\'on entre el ascensor y el piso se compara con un procutor/consumidor. Al igual que entre
					el controlador y el ascensor, se tiene un procutor (el piso) y un consumidor (el ascensor). Sin embargo, a diferencia del primer caso, 
					ahora se tiene un repositorio diferente por cada productor, mientras que antes todos los pisos utilizaban el mismo repositorio, ahora cada
					uno de los pisos cuenta con un buffer particular que comparte con el ascensor. (Como se ver\'a m\'as adelante, en realidad son dos buffer 
					los que comparten cada piso con el ascensor, esto se debe a que se debi\'o diferenciar a las personas que iban a pisos superiores al actual 
					de las que iban a pisos inferiores).
					\item \textbf{Comunicaci\'on entre el terminador y el piso}
					\item \textbf{Comunicaci\'on entre el piso y el controlador}
					\item \textbf{Comunicaci\'on entre el terminador y el ascensor}\\
					\\En estos \'ultimos tres casos, dado que la comunicaci\'on no requiere intercambio de informaci\'on especifica (si no que solo se realizan 
					avisos de finalizaci\'on), no fue necesario encontrar una soluci\'on m\'as elaborada que los mecanismos de concurrencia b\'asicos conocidos, 
					como los son, los sem\'aforos, o las se\~nales.
				\end{itemize}
				
		\subsection{Mecanismos de concurrencia utilizados}
			\indent Una vez analizado todo el dise\~no de la soluci\'on, asi como tambi\'en los procesos que incluye, y la comunicaci\'on entre los mismos, vamos a enunciar y
			justificar el por qu\'e de los mecanismos de concurrencia elegidos.
			\indent Por un lado, se debe resolver el intercambio de datos entre los procesos (utilizando por ejemplo memorias compartidas, pipes, o fifos), por otro, se 
			debe analizar la forma de sincronizar el acceso a dichos datos, asi como tambi\'en sincronizar a los procesos mismos, evitando por ejemplo que un padre finalice
			su ejecuci\'on antes que un hijo, (utilizando sem\'aforos, locks, etc), y por \'ultimo, se debe buscar la forma de comunicar a los procesos, de forma tal que 
			puedan intercambiar alg\'un tipo de mensaje (utilizando en este caso se\~nales).
			\indent A continuaci\'on se enuncia para cada tipo de cominucaci\'on entre los diferentes procesos, los mecanismos utilizados para comunicar, sincronizar y 
			intercambiar informaci\'on.
			\begin{itemize}
				\item \textbf{Comunicaci\'on entre el piso y el controlador:}\\
				Como se mencion\'o a lo largo de este informe, cada un intervalo aleatorio de tiempo, en cada piso se crea una persona, simulando la llegada de la
				misma al ascensor. Adem\'as, como la idea es simular la realidad, no se pod\'ia restringir de ninguna forma, de que en pisos diferentes, lleguen en el mismo
				instante de tiempo personas diferentes. Este comportamiento gener\'o el problema de indicarle al ascensor a que pisos hab\'ia llegado cada una de las personas. 
				En primera instancia se pens\'o utilizar el env\'io de se\~nales para dicho prop\'osito, sin embargo la soluci\'on se vio descartada dado el comportamiento 
				err\'atico que puede presentar una se\~nal, si cuando est\'a siendo manejada, llega una nueva se\~nal del mismo tipo.\\
				Para simplificar este problema, lo que se hizo fue separar en procesos m\'as simples el comportamiento del ascensor, se creo un nuevo proceso 
				denominado \emph{Controlador}, mientras que el proceso \emph{Ascensor} se encarga del movimiento del mismo, es el Controlador, el encargado de resolver los
				pedidos que le llegan. Entonces, cada vez que una persona llega a un piso, no le avisa directamente al ascensor, si no que lo hace al controlador, 
				y este si es el encargado de alertar al ascensor del nuevo pedido.\\
				Sin embargo esta separaci\'on de procesos, no resuelve el problema de que m\'as de un piso, le intente avisar al controlador de un nuevo pedido al mismo
				tiempo. Es por eso que se opto por no utilizar se\~nales para la comunicaci\'on, si no enviar directamente el pedido a trav\'es de un \emph{pipe}. El 
				comportamiento bloqueante de un pipe, hace que de llegar m\'as de un pedido simult\'aneo, solo uno pueda avisarle al controlador, mientras que los demas quedan
				bloqueados esperando que este finalice su tarea. Es decir que los pisos lo \'unico que hacen al crear una nueva persona es pedir el acceso al pipe, y cuando
				se le otorga colocan la informaci\'on pertinente en el mismo.\\
				Por otro lado, el controlador debe estar siempre a la escucha de dicho pipe, para ir resolviendo los pedidos a medida que se van generando. Si en 
				alg\'un instante de tiempo, se da el caso de que ning\'un piso requiera el ascensor, entonces el controlador queda blqueado autom\'aticamente en el pipe 
				esperando a que llegue un nuevo pedido.

				\item \textbf{Comunicaci\'on entre el controlador y el ascensor:}\\
				En el apartado anterior, se describi\'o de qu\'e forma, un piso le avisa al controlador que un nuevo pedido fue realizado. En este caso, se procede a describir
				de que forma, el controlador le avisa al ascensor que llego un nuevo pedido.\\
				En este caso, lo que se planteo fue que si bien son varios los pisos que pueden realizar pedidos al mismo tiempo, al existir solo un ascensor, dichos pedidos
				solo se pueden resolver de a uno. Es por eso que el intercambio de informaci\'on entre el controlador y el ascensor es de a un pedido por vez.\\
				A diferencia del caso anterior, el ascensor no va a estar siempre a la espera de nuevo pedidos (como lo estaba el controlador), si no que siempre va a estar
				resolviendo los pedidos que ya se le hab\'ian realizado.\\
				Como el ascensor no est\'a siempre a la escucha de nuevos pedidos, se debi\'o implementar una forma de avisarle al ascensor que un nuevo pedido se hab\'ia 
				realizado, y ademas brindarle la informaci\'on pertinente a dicho pedido. \\
				Esta vez se opt\'o por la utilizaci\'on de se\~nales y una memoria compartida. El controlador al recibir un pedido coloca la informaci\'on de dicho 
				pedido en la memoria compartida, y adem\'as, como el ascensor no est\'a constantemente leyendo la memoria, le manda una se\~nal para que lo haga. El ascensor al 
				recibir dicha se\~nal lee la memoria compartida, y se almacena el pedido realizado.\\
				En este caso, no se tiene el problema de varias se\~nales simult\'aneas. Esto se debe a que el controlador deposita la informaci\'on en la memoria compartida 
				y le manda una se\~nal al ascensor. Sin embargo, dado que se utilizaron sem\'aforos de lectura y escritura para la sincronizaci\'on, el controlador no puede 
				enviarle una nueva se\~nal al ascensor, hasta que este \'ultimo no haya retirado la informaci\'on de la memoria compartida y liberado el semaforo de 
				escritura. Y adem\'as el ascensor no libera el semaforo de escritura hasta que no haya terminado de ejecutar el manejador de la se\~nal.\\
				Entonces, el comportamiento del controlador ser\'ia quedar a la espera de nuevos pedidos, cuando le llega un nuevo pedido, lo coloca en la memoria compartida
				y le avisa al ascensor mediante una se\~nal, luego el controlador, si recibe un nuevo pedido, queda a la espera que se libere el sem\'aforo de escritura. El 
				ascensor por su parte va a estar resolviendo los pedidos que ya tenia acolados, hasta que le llegue una se\~nal, cuando esto sucede, este detiene su 
				ejecuci\'on y lee el nuevo pedido. Una vez leido el pedido, se libera el semaforo de escritura y se continua resolviendo los pedidos acolados.\\
				Si al ascensor no le quedan pedidos por resolver, este detiene su ejecuci\'on (pasa a estado dormido/esperando) mediante pause hasta recibir una nueva se\~al
				que le indique como debe continuarsu ejecuci\'on. 
				
				\item \textbf{Comunicaci\'on entre el ascensor y el piso:}\\
				En las dos secciones anteriores se detall\'o la forma en que los pedidos son recibidos. A continuaci\'on se procede a explicar de que forma son resueltos.\\
				Al recibir un pedido, la informaci\'on que necesita el ascensor es el piso en el cual se realiz\'o el pedido y si el usuario desea subir o bajar en el 
				ascensor. Dicha informaci\'on es enviada a traves del pipe de pedidos al controlador y este se la pasa al ascensor a trav\'es de la memoria compartida. Una
				vez recibido el pedido, el ascensor lo coloca en su lista de pedidos, reordena dicha lista y se dirige al pr\'oximo piso que deba visitar. Al llegar al piso,
				se pueden tener dos casos, por un lado, se puede llegar al piso porque una persona desde dentro del ascensor desea bajarse en el piso, o por otro lado, una 
				persona externa desea subirse al ascensor.\\
				En el primer caso, el ascensor desciende a las personas y continua su camino al siguiente pedido de la lista, sin intercambiar informaci\'on con el piso.\\
				En el segundo caso la situaci\'on es m\'as compleja. El ascensor debe llegar al piso, y debe permitir a las personas que lo estaban esperando que entren al 
				mismo, siempre y cuando no se sobrepase la capacidad m\'axima. Para poder brindarle la informaci\'on de las personas al ascensor, nuevamente 
				se opto por la utilizaci\'on de un pipe. Al llegar una nueva persona al piso, este no solo le avisa al controlador del nuevo pedido, si no que tambi\'en 
				coloca esta persona en el pipe de comunicaci\'on con el ascensor. Con cada nueva persona que llega al piso, es un nuevo pedido que se le hace al 
				controlador, y una nueva persona que se coloca en el pipe. Al llegar el ascensor al piso lee del pipe, tantas personas como pedidos de ese piso haya 
				recibido, o tantas personas como entren seg\'un la capacidad. En el caso de que no se pueda resolver un pedido por estar sobrepasada la capacidad, dicho
				pedido se deja colocado en la lista de pedidos del ascensor, y la persona no es leida del pipe. Al hacer esto, se logra que la pr\'oxima vez que el ascensor
				pase por este piso, puedan ingresar todas las personas que no puedieron hacerlo originalmente.\\
				Finalmente aclarar que como se mencion\'o anteriormente, la comunicaci\'on entre el ascensor y el piso se realiza mediante dos pipes, uno en el cual est\'an
				a la espera las personas que quieran ir a pisos superiores, mientas que el segundo es para las personas que desean ir a los pisos inferiores. Cuando el
				ascensor llega al piso, lee solamente el pipe que le corresponde de acuerdo al estado que se encuentra el ascensor (subiendo o bajando) y el pedido que 
				fue realizado.
				
				\item \textbf{Comunicaci\'on entre el terminador y el piso:}\\
				Una vez finalizado el tiempo que debe durar la simulaci\'on, el terminador debe indicarle a los pisos que ya no se pueden recibir m\'as pedidos. Dado que no 
				se requiere ning\'un intercambio de informaci\'on especifica, en este caso se utilizaron nuevamente las se\~nales para llevar a cabo el objetivo.\\
				Cuando se terminan de crear todos los procesos, el terminador pasa a dormir el tiempo que se indic\'o por parametro en la aplicaci\'on, al finalizar dicho
				intervalo de tiempo, el terminador se despierta y le manda una se\~nal a cada uno de los pisos para que estos dejen de generar pedidos y finalicen su 
				ejecuci\'on de forma ordenada.
				
				\item \textbf{Comunicaci\'on entre el piso y el controlador:}\\
				Dado que al finalizar la simulaci\'on, se deben finalizar todos los procesos lanzados para la ejecuci\'on de la misma, se debi\'o buscar la mejor forma de
				indicarle a cada uno de los procesos que deb\'ia terminar. En el caso del controlador, se aprovecho nuevamente la propiedad bloqueante de los pipes.\\
				Como se mencion\'o anteriormente, el controlador est\'a constantemente a la espera de nuevos pedidos, bloqueado leyendo del pipe. Sin embargo cuando finaliza 
				la ejecuci\'on de todos los pisos, estos se encargan de cerrar el pipe de escritura con el controlador. Al cerrarse todos los pipes de escritura, el pipe
				de lectura se libera autom\'aticamente, haciendo que el controlador finalice su ejecuci\'on.
				
				\item \textbf{Comunicaci\'on entre el terminador y el ascensor:}\\
				Una vez terminada la ejecuci\'on de todos los pisos (y por lo tanto tambi\'en la del controlador), solo queda finalizar al proceso que controla al ascensor.\\
				Para ello, nuevamente el terminador le env\'ia una se\~nal al proceso para que termine su ejecuci\'on de forma ordenada. Sin embargo, en este caso, el 
				ascensor al recibir la se\~nal, debe resolver todos los pedidos que le quedaban pendientes antes de terminar su ejecuci\'on.
			\end{itemize}

		\subsection{Logger}
			\indent Uno de los requerimientos no funcionales de la aplicaci\'on era la generaci\'on de un registro de todas las operaciones que se llevan a cabo. Dicho 
			registro resulta de gran utilidad a la hora de desarrollar aplicaciones concurrentes en donde seguir la ejecuci\'on del programa presenta una dificultad considerable.\\
			\indent Para generar este archivo de registro se creo una clase encargada de registrar todos los mensajes que se le env\'ian en un \'unico archivo
			denominado \textquotedblleft {\it Log\textless fecha\textgreater\textless hora\textgreater.txt} \textquotedblright, d\'onde \textless fecha\textgreater 
			y \textless hora\textgreater se corresponden con el momento de inicio de la ejecuci\'on del programa. 
			Cada vez que un proceso desea registrar un mensaje, se lo debe indicar a la clase Log, la cual se implement\'o mediante un patr\'on Singleton.\\
			\indent Dado que todos los procesos registran mensajes con el mismo Logger y en el mismo archivo de registro, se debi\'o sincronizar el uso del mismo mediante el uso
			de locks, los cuales evitan que m\'as de un proceso escriban al mismo archivo al mismo tiempo, dando como resultado un mensaje inv\'alido.\\
	
	\section{Diagramas de Clases}

		\subsection{Diagrama de Clases Ascensor}
			\begin{figure}[!htpb]
				\centering
				\includegraphics[width=14cm]{Diagramas de clases/Diagrama de clases.png}
				\caption{Diagrama de Clases Ascensor}
			\end{figure}
		\newpage
		\subsection{Diagrama de Clases Se\~nales}
			\begin{figure}[!htpb]
				\centering
				\includegraphics[width=8cm]{Diagramas de clases/clases seniales.png}
				\caption{Diagrama de Clases Se\~nales}
			\end{figure}
		\newpage
		\subsection{Diagrama de Clases Logger}
			\begin{figure}[!htpb]
				\centering
				\includegraphics[width=6cm]{Diagramas de clases/clases Logger.png}
				\caption{Diagrama de Clases Logger}
			\end{figure}
		\newpage
		
	\section{Diagrama de Transici\'on de Estados del Ascensor}
		\begin{figure}[!htpb]
			\centering
			\includegraphics[width=12cm]{Diagrama de transiciones/diagrama Transiciones.png}
			\caption{Diagrama de Transici\'on de Estados}
		\end{figure}

	
\end{document}
